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REGIONAL FARE COORDINATION SYSTEM 

CHANGE ORDER NO. 32 

CONTRACTOR: ERG Transit Systems (USA) Inc. 

CONTRACT NUMBER: 229944 

This Change Order to Contract #229944 (“Change Order”) is executed as of j^/ffiand 
between ERG Transit Systems (USA) Inc, a California corporation and wholly owned subsidiary of 
ERG Limited, an Australian corporation, (hereinafter referred to as the “Contractor) and each of the 
following seven public transportation agencies (hereinafter referred to individually as an “Agency or 
collectively as the “Agencies"): 

1. Central Puget Sound Regional Transit Authority ("Sound Transit") 

2. King County ("King County") 

3. Kitsap County Public Transportation Benefit Area ("Kitsap Transit") 

4. Pierce County Public Transportation Benefit Area (“Pierce Transit”) 

5. Snohomish County Public Transportation Benefit Area ("Community Transit") 

6. City of Everett (“Everett”) 

7. State of Washington, acting through the Washington State Department of Transportation, 
Washington State Ferries Division ("WSF") 

Background 

A. Effective April 29, 2003, each of the Agencies and the Contractor entered into Contract #229944 
(“Contract”) to implement a Regional Fare Coordination System (“RFC System”) to establish a 
common fare system utilizing smart card technology. The Contractor is responsible for the 
development, implementation, operation and maintenance of the RFC System as specified in the 
Contract. 

B. The Contract requires that the Contractor provide to the Agencies the software tools, interface 
specifications, documentation, information, training and other materials, as well as a certification 
process that will enable the Agencies and their other contractors to create and install non-RFCS 
applications on, or interfacing with, the Driver Display Unit (“DDU”) and modify the DDU user interface 
for such non-RFCS applications and interfaces. 
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C. King County (“the County”) has entered into a separate contract for an On-Board 
Systems/Communications Center System (OBS/CCS) which will be integrated with the DDU in the 
"full integration mode" (FIM) described in Section 6.111-6.8 of the Contract. As provided by Section 
6.111-6.8.1 of the Contract, the DDU shall support FIM. As provided by Section 6.111-6.8.5, the 
development of new non-RFCS applications on the DDU shall be subject to an agreed upon 
certification process. 

D. As contemplated in Change Order 22, staff from the Contractor, the County, and the County's 
OBS/CCS contractor met to discuss the integration of the OBS/CCS functions with the current DDU. 
At the County’s request, the Contractor has proposed that certain changes to the current DDU and 
Radio Control Unit (RCU) functionality will better enable the DDU to integrate with, and support, the 
OBS/CCS functions while not negatively affecting the DDU functionality required for the other 
Agencies. 

E. The Agencies desire to enter into this Change Order No. 32 to authorize the Contractor to proceed 
with the design, development, testing and implementation of the changes to the DDU and RCU, and 
the other Work set forth herein, as necessary to provide the functionality described below. 

F. The Agencies desire to enter into this Amendment 128, attached hereto as Change Order 32 - 
Attachment B, in order to align Change Order 32 with the agreed Work, Schedules and Payment 
Milestone entrv/exit criteria. The Agencies introduced new Work via RFCS RFI 607 FIM Distribution 
for KCM OBS which resulted in schedule modifications to KCM and INIT’s work as originally agreed in 
Change Order 32. 


Agreements 


The Agencies and the Contractor hereby agree to the following: 


1.0 General 

In accordance with the Contract and this Change Order, the Contractor shall design, develop, test and 
implement changes to the DDU and RCU that provide the functionality described below in Section 2.0. 

As set forth in Section 3.0, the Contractor shall provide training and technical support for the 
OBS/CCS vendor in its development of a non-RFCS application for the DDU and that application’s 
integration with the Contractor’s DDU and RCU applications. 

As set forth in Section 4.0, the Contractor shall also provide a detailed plan and schedule for, and 
perform the work of, testing the modified DDU and RCU applications developed by the Contractor, 
testing the integration of said modifications with the application developed by the OBS/CCS vendor, 
certifying that all new or modified applications (both those developed by the Contractor and those 
developed by said OBS/CCS vendor for use with the DDU) do not adversely affect the operation of 
the RFCS, and releasing all of the new or modified applications into the RFCS Regional Test Bed 
(RTB) and then into the production environments. 

As set forth in Section 5.0, the Contractor shall update the applicable design, training and certification 
process documents. 


Change Order 32 Amended by Attachment B - Amendment 128 


2 







2.0 Changes to Division III 

2.1 Section 6.111-4.1 is amended to read as follows: 

6.111-4 On-Board Fare Transaction Processor (OBFTP) 


6.111-4.1 Subsystem Description - OBFTP 

The Contractor shall provide On-Board Fare Transaction Processors (OBFTP) allowing fare cards to be 
read and encoded through the contactless interface during the fare payment process on-board Agency 
coaches. The OBFTP shall consist of a CPU for processing transactions, memory for storing fare tables 
and transaction records, customer display, and card reader (DR 102.05). 

The OBFTP shall be capable of operating, when delivered, in a limited integration mode (LIM) or as a 
plug-n-play peripheral in full integration mode (FIM) on an on-board network to be provided by others. 
Initially, the Agencies expect to operate the OBFTPs with a limited degree of integration, and then 
migrate to a full integration mode when an on-board Vehicle Logic Unit (VLU) is developed and installed 
by others (see Section 6.111-5). 

A flexible architecture for the OBFTP (DR 102.06) and DDU is required to allow each agency to migrate 
from the limited integration mode to the full integration mode at any time in the future and to 
accommodate on-board integration requirements and architectures that vary by Agency. The OBFTPs, 
when delivered, shall be capable of supporting the following two modes of operation, and shall be 
designed to allow migration from limited to full integration mode without hardware or operating/RFCS 
application software changes, except such hardware and software changes as necessary to achieve the 
objectives of Change Order No. 32. 

The Ethernet switch will be installed as per Section 6.11-11.3 for the purpose of providing an 
environment that allows for developing a modular on board architecture as per contract clause 6.III- 
3.4.6. When installed, the Ethernet switch will function as the communications switch for all on-board 
system traffic for fare collection purposes. The Ethernet switch shall provide communications between 
the OBFTP, DDU, and VLU in full integration mode. The OBFTP and DDU, and VLU at an Agency’s 
discretion, shall transfer data to the WDOLS via an Ethernet switch/High Speed serial interface when 
communicating on and off the vehicle in FIM. 

4.1.1 Limited Integration Mode (LIM) 

In the Limited Integration Mode, the OBFTP shall store transactions until communication with 
the WDOLS is established and data transfer can be completed. The OBFTP shall connect to 
other on-board devices as illustrated in Figures 111-4.1 and 111-4.2. 
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Figure 111-4.1 (KCM) 
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On-Board LIM Architecture for KC Integration 


Figure III-4.2 identifies the module interfaces that apply to the Limited Integration Mode (LIM). 


Figure 111-4.2 
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4.1.2 Full Integration Mode (FIM) - King County 

In the Full Integration Mode, the VLU, DDU and the OBFTP shall share the use of the 
WDOLS for coaches owned or operated by King County. When communication is 
established via the WDOLS, then the data transfers for each device will be handled in 
parallel until all are completed. The OBFTP, DDU and WDOLS shall be connected as 
illustrated in Figures III-4.3 and III-4.4. 

The Ethernet switch shall act as_the interface between the OBFTP, DDU and VLU. The 
VLU shall send data and information as described herein to the DDU. The DDU will 
share the information from the VLU with the (AFC Application) by use of the DDU 
Common Store. An Ethemet/High Speed Serial interface shall be used for on/off¬ 
loading data via the WDOLS. Data provided by the VLU will include the variables 
described in Section 6.III-6.8.4, including but not limited to: login data (route/run/trip), 
trip change prompts, fareset changes and, if the ERG option is exercised. Stop ID data. 
The AFC Application will update the Common Store variables needed by the OBS, 
including but not limited to: operator login and default trip fareset. 


F ig u re III - 4 .3 (C T ) 

On-Board Architecture for CT Integration 
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Figure III - 4.3 (PT/ET/KT) 


On-Board Architecture for PT, ET, and KT Integration 
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Figure III - 4.3 (KCM - revised by C.O. 32) 
On-Board Architecture (FIM) for KCM Integration 
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Figure III-4.4 identifies the module interfaces that apply to the Full Integration Mode (FIM). 
The Contractor may suggest alternative on-board configurations in addition to the configuration 
provided, subject to the review and approval of the Contract Administrator. 


Figure 111-4.4 

MODULE INTERFACE SUMMARY - FIM 
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2.2 Section 6.111-6.8.5, "Application Certification," is renumbered Section 6.111-6.8.7. 

2.3 Section 6.111-6.8.5 shall read as follows: 

6.8.5 King County FuM Integration Mode (FIM) 

6.8.5.1 General 

The Contractor shall provide applications, software, test elements, and testing for the 
integration of the Driver Display Unit (DDU) with the On-Board Systems (OBS) being 
developed by another vendor (OBS/CCS vendor). Such integration shall be implemented on 
King County coaches and Sound Transit coaches operated by King County (hereinafter 
collectively referred to as KCM coaches). 

The DDU shall be modified to provide for two modes of operation: 

1. Limited Integration Mode (LIM) representing the current (pre-OBS) condition and 
operations, as well as the current condition and operations of all other Agencies. 

2. Full Integration Mode (FIM) representing King County on-board system operation when 
the OBS equipment is installed and operational. 

Modifications to the DDU shall not adversely affect operation on the device on other (non-King 
County or Sound Transit coaches operated by others) coaches or services, or introduce 
additional steps or workload for the operators of those services. 

As required in Section 6.111-6.8.1 and 6.8.3, the DDU will be integrated with the RCU and King 
County's existing on-board systems in limited integration mode (LIM) until all KCM coaches 
have new OBS and Transit Radio Systems installed. For FIM, the Contractor shall provide 
design, development and testing documentation, software tools and test apparatus, as agreed 
upon by the Parties , for the OBS/CCS vendor to develop a new on-board non-RFCS 
application ("OBS Application") that will reside on the KCM DDU platform and integrate with 
the VLU (Vehicle Logic Unit) being supplied by the OBS/CCS vendor. 

The Contractor shall be responsible for development, modification, integration and testing of 
all RFCS software on the DDU, RCU and On-Board Fare Transaction Processor (OBFTP) as 
required to provide the functionality described herein, and maintain RFCS fare collection 
functionality and operations. All applicable devices in the KCM coaches shall be updated with 
new software containing the OBS Application and updated AFC and RCU applications as 
required to support both LIM and FIM functionality prior to the first phase of installation of OBS 
equipment. 
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For purposes of this Section, the following terms shall have the following meanings: 

a. Automatic Fare Collection (AFC) Application: Contractor-developed RFCS software that is 
necessary to meet the requirements of this Section, including on-board software related to 
the DDU and OBFTP, as well as any test and back office software that is created or 
revised to meet the requirements of this Section. 

b. DDU Monitor Application: Contractor-developed application to be provided to the 
OBS/CCS vendor for display of additional DDU Common Store variables and variable sets 
via diagnostic interface. 

c. OBS Application: the non-RFCS application to be developed by the OBS/CCS vendor and 
loaded onto the DDU, which will integrate with the Vehicle Logic Unit (VLU). The VLU, in 
turn, manages the OBS devices and interfaces, such as the new 700 MHz radio system. 

d. OBS Stub Application: Contractor-developed application to be deployed to all RFCS 
'coaches to communicate configuration status to the AFC Application. LIM mode will be the 
default configuration until the OBS Application detects the presence of OBS equipment. 

e. RCU Application: Contractor-developed software required to operate the King County 
Radio Control Unit (RCU) and provide functionality described in 6.8.5.4 of this Change 
Order. 


6.8.5.2 DDU Monitor Application 

The Contractor shall provide a DDU Monitor Application, which will be a development tool for 

displaying additional DDU Common Store variables and variable sets via a diagnostic 

interface. 

6.8.5.3 OBS Stub Application/Test Harness 

a. The Contractor shall develop an OBS Stub Application, the role of which is to communicate 
to the AFC Application, via the FlMConfig mechanism, described below, that LIM mode is 
enabled in the absence of OBS equipment. The Stub Application will be deployed to all 
RFCS Agency coaches as part of the revisions to the AFC Application prior to 
implementation of the OBS Application in order to confirm that changes to the AFC 
Application have not affected RFCS functionality. On coaches operated by King County, 
the OBS Stub Application will be replaced by the OBS Application once it is available and 
has been certified by the Contractor per the provisions of Section 4.0 of this Change Order. 

b. The Contractor shall provide a testing capability for OBS operations that affect the DDU. A 
set of test commands will be created via the DDU Monitor Application. These test 
commands will be limited to providing a mechanism to manually modify and validate the 
contents of the new variable sets added to the DDU Common Store in order to implement 
this Change Order. 

c. The OBS Stub Application may also be used as a development tool to provide simulation 
of various on-board operations to aid in the development of software for AFC Application 
integration. 
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6.8.5.4 RCU Application 

a. Rather than duplicate a large number of existing DDU template resources, the OBS 
Application and RCU Application will share the appropriate existing template resources. 
The decision on which of these applications accesses the shared template resources is to 
be made by the OBS Application based on whether or not FIM mode is enabled. 

b. The Contractor shall modify the RCU Application to only access the existing template 
resource once LIM mode has been detected. In the case of FIM mode being detected, the 
RCU Application shall be modified to behave in a passive manner to allow the OBS 
Application to gain access to the existing template resources and perform the desired FIM 
mode operations. 

c. The operation of the existing RCU Application shall be maintained for LIM until every KCM 
coach has been equipped for FIM. 


6.8.5.5 OBS Application and AFC Application Changes for FIM Configuration 

a. The OBS Application shall be separate and distinct from the existing RCU Application 
that interfaces with the legacy KCM radio system. The operation of the existing RCU 
Application shall be maintained for LIM until every KCM vehicle has been equipped for 
FIM. 

b. The OBS Application shall be downloaded by the Contractor to the DDU prior to 
installation of OBS hardware per an agreed upon schedule. The OBS Application will 
detect the presence (FIM mode) or absence (LIM mode) of OBS hardware. The OBS 
Application will provide integration status to the DDU and AFC applications which shall 
self-configure accordingly without the need for driver input or action. 

c. The OBS Application will notify the AFC Applications of the integration state (either LIM 
or FIM) so that operations with legacy radio equipment via the RCU Application can be 
maintained until the deployment of OBS hardware on each vehicle. The Contractor 
shall provide a mechanism via the DDU Common Store that allows the OBS 
Application to communicate this information to the AFC applications. This mechanism 
shall be referred to as FlMConfig. 

Login Process 

d. From the user viewpoint the login screens and process will appear the same in LIM 
and FIM. For FIM, the login process will be shared between the AFC and OBS 
Applications. The AFC Application will continue to manage Operator login and 
validation. The AFC Application will provide the Operator login data and status to the 
OBS via the DDU Common Store. 

e. The OBS Application shall take over the responsibility of managing route/run entry and 
trip selection and will also be responsible for the communication of the resulting trip 
login information to the AFC Application. To support this requirement, the Contractor 
shall provide a mechanism via the AFC Application, using the DDU Common Store that 
allows the OBS Application to communicate login information to the AFC application as 
required. This mechanism will be referred to as FIMTripInfo. 

f. An agency-defined, unique Trip ID will be provided by KCM to the OBS and RFCS 
devices. Across a year’s three major service changes and the bi-weekly Configuration 
Data (CD) distributions, these Trip IDs will not be re-used. Also, for the life of a major 
service change, a Trip ID will always refer to the same trip. These two conditions are 
required to avoid undetected mismatches in datasets between the two systems. The 
Contractor shall modify CD formats to allow such agency Trip ID to be delivered to the 
DDU/OBFTP 
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Automatic Next Trip Selection 

g. To support the OBS-lnitiated route/run/trip selection requirement, the Contractor shall 
provide functionality to enable the implementation of the following sequence of events 
while in FIM mode: 

1. At a point in time just prior to reaching the end of trip location, the OBS 
Application shall direct the DDU to display a message in its VLS window asking 
the driver to confirm the change to the next trip, and also display the "Start Next 
Trip" icon for the driver to press the associated key to trigger this confirmation. 

2. After the Operator presses the “Next Trip” button, the OBS Application shall 
notify the AFC Application of the change to the next trip via the FIMTripInfo 
mechanism. 

3. The AFC Application shall validate the trip information provided by the OBS 
Application. If an error occurs, an error message shall be returned to the OBS 
Application via the FIMResult mechanism. If successful, the AFC Application 
shall complete the change to the next trip, communicate the appropriate 
information as positive feedback to the OBS Application and set the AFC device 
mode to "On-Trip." 

4. New trip and fare information shall be displayed on the DDU. 

Automatic Fare Change at Zone Boundaries 

h. To support the OBS-lnitiated fare change requirement, the Contractor shall provide 
functionality to enable the implementation of the following sequence of events while in 
FIM mode: 

1. The AFC CD will set the default fare table and initial Distance Code at the start 
of each trip. The fare table defines the range of fare alternatives that are 
possible for the selected trip. 

2. The Contractor shall provide functionality for the OBS Application to 
communicate a desired fare change to the OBFTP based on the vehicle’s 
location. This mechanism will be referred to as FIMFareset. 

3. The Contractor shall provide functionality for the AFC Application to 
communicate to the OBS Application whether or not the driver has manually 
changed the current default fare since the start of the current trip. This 
mechanism will be referred to as FIMStatus. 

4. The Contractor shall provide for the AFC Application to communicate to the 
OBS Application whether any OBS-communicated fare set change was 
successful or unsuccessful and return the result as FIMResult. 

5. If the AFC Application is on-trip and it receives a request by the OBS 
Application to change the current default Distance Code via the FIMFareset 
mechanism, and the driver has NOT manually changed the current distance 
code since the start of the current trip, then the AFC Application shall: 

o Automatically change the current default fare in use by the AFC 
Application, and 

o Notify the OBS Application that the request was successful via the 
FIMResult mechanism. 

6. If the AFC Application is on-trip and it receives a request by the OBS 
Application to change the current default fare via the FIMFareset mechanism, 
and the driver has manually changed the current fare since the start of the 
current trip, then the AFC Application shall: 
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o notify the OBS Application that the request was unsuccessful via the 
FIMResult mechanism. 

7. When the driver manually changes the default fare on the AFC Application via 
the Change Fare function, the AFC Application shall notify the OBS Application 
of this via the FIMStatus mechanism. 

8. The Initial Trip Distance Code, fare table(s) and peak/off peak designator, will 
come from RFCS CD as exported by KCM. The default fare can be overridden 
by the driver and the driver will retain the ability to manually select from the 
available fare tables for the trip. 

9. OBS initiated fareset changes will be limited to the valid distance codes in the 
AFC designated default fare table. 

10. The OBS Application shall not include functionality to automatically set or 
change the fare table as part of the fareset change. 

11. When the Operator begins a new trip the AFC Application will reset the default 
fare table and Distance Code for that trip. 


6.8.5.6 CCS Initiated Changes 

a. While operator login/logoff will still generally be performed by the existing DDL! 
applications, the OBS Application also will be able to automatically initiate an operator 
login/logoff or update certain login-related parameters such as route/run/trip selection. 

Such commands will be issued by the OBS based on instructions sent from the 
Communications Center System (CCS) by a Communications Coordinator (dispatcher). 
Such operation shall be referred to as a "CCS-lnitiated" login/logoff or login parameter 
change (route/run/trip). To support this requirement, the Contractor shall provide 
functionality in the AFC Application (using the DDU Common Store) to allow the OBS 
Application to communicate operator login, operator logoff to the AFC Applications via the 
FIMLogon mechanism, and/or route/run/trip selection to the AFC Applications via the 
FIMTripInfo mechanism. When a Coordinator using the Communications Center System 
(CCS) provides the OBS Application with an operator ID to log in, a password is not 
required. 

b. The Contractor shall provide functionality in the AFC application (using the DDU Common 
Store) to communicate the result of CCS-initiated Operator login/logoff and/or route/run/trip 
selection back to the OBS Application via the FIMResult mechanism. 

c. To support the CCS-lnitiated operator login requirement, the Contractor shall provide 
functionality to enable the implementation of the following sequence of events while in FIM 
mode: 

1. The OBS Application shall communicate the required information via the FIMLogon 
mechanism as specified above. 

2. The AFC Application shall validate the information provided by the OBS Application 
as required for fare collection operation. 

3. If a validation error occurs, an error message shall be returned to the OBS 
Application via the FIMResult mechanism. If successful, the AFC Application shall 
complete the login process, communicate the appropriate information as positive 
feedback to the OBS Application and set the DDU/OBFTP device Mode to "Off- 
Trip." 

4. The OBS Application shall determine whether or not to display Route/Run Entry 
and Trip Selection screens before triggering a route/run/trip change. 
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d. To support the CCS-initiated operator logoff requirement, the Contractor shall provide 
functionality to enable the implementation of the following sequence of events while in FIM 
mode: 

1. The OBS Application shall communicate the required information via the FIMLogon 
mechanism. 

2. If an error occurs with logoff, an error message shall be returned to the OBS 
Application via the FIMResult mechanism. If successful, the AFC Application shall 
complete the logoff, communicate the appropriate information as positive feedback 
to the OBS Application, and set the DDU/OBFTP device mode to "Login." 

3. The AFC Application shall display the normal login screen sequence. 


6.8.5.7 Display of Debugging/Maintenance Variables 

The Contractor shall provide a mechanism via the DDU Common Store for the OBS 
Application to display a set of 10 variables for debugging/maintenance purposes. The values 
of these variables shall be provided via the DDU’s diagnostic port. The OBS/CCS vendor will 
be responsible for providing a list of such variables and their descriptions. 


3.0 Training and Technical Support 

3.1 The Contractor shall provide training and technical support to the OBS/CCS vendor as 
needed to enable the following work: 

a. design of the template resources required for the development of the OBS Application; and 

b. development of the OBS Application. 

3.2 Such training and technical support shall be provided on an as-needed basis by 
telephone or email. In addition, the Contractor agrees to provide the following on-site support: 

a. Contractor’s software engineer will travel to the OBS/CCS vendor’s facility in Germany for 
a 1-week period to provide on-site technical support to INIT in its development efforts; 

b. Contractor’s software engineer will travel to the OBS/CCS vendor’s facility in Germany for 
a 1-week period to assist in the integration of the OBS Application with the DDU/OBFTP; 
and 

c. Contractor’s test engineer will travel to Seattle for a 4-week period to observe and 
participate in the RTB and field testing of the modified AFC Application, RCU Application 
and the OBS Application. 

3.3 The Contractor shall participate in KCM’s Technical Interface Committee (TIC) if 
requested. TIC sessions will be conducted remotely via teleconference or locally when 
Contractor is already providing on-site support in Seattle. 

a. All parties are required to provide support for the integration of the DDU/OBFTP and the 
OBS Application as detailed herein. The technical relationship between the two projects 
requires both the contractors to be willing and able to work openly and collaboratively with 
one another without prejudice or bias regardless of historical relationships. To this end, the 
Contractor shall work cooperatively with the OBS/CCS contractor, within the scope of this 
agreement, as directed by the KCM Project Manager. 

b. The purpose of the TIC will be to address and successfully resolve integration and 
interface issues between the Regional Fare Coordination System and the On-Board 
Systems/Communications Center System. In this forum, facilitated by KCM staff, the 
Contractor and the OBS/CCS vendor shall exchange information and resolve issues 
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related to the definition and development of their required interfaces, interface 
documentation, and interface test plans. 

c. The TIC will not necessarily address and does not relieve the Contractor and the 
OBS/CCS vendor of their responsibilities to provide other integration and interface 
deliverables such as attending design review meetings; providing interface control 
documents, equipment prototypes and production units; coordinating installation; and 
meeting testing requirements. 


4.0 Design Review, Testing and Certification Plan 

4.1 The Contractor shall prepare a detailed written Plan for the design review, testing and 

Certification of the AFC, RCU, DDU Monitor, OBS Stub, and OBS Applications as specified in 
this Change Order No. 32, whether new or modified in accordance with Contract Division III, 
Section 6.8.5 At a minimum, the Design Review, Testing and Certification Plan shall provide for 
the following: 


Step One: Design Review and Approval (by Contractor and Agencies) 

Step Two: Development and Testing in Development Environment (FAT and SIT) 
Step Three: Pre-Release Testing in Contractor's Seattle Regional Test Bed (RTB) 
Step Four: Installation and field testing on sample KCM vehicles 



4.2 The description of each step shall include all applicable testing strategies, plans, test equipment, 
scripts, duration, performance measures, location and schedule information. The description 
shall be submitted to the Contract Administrator, the KCM OBS/CCS Project Manager and the 
OBS/CCS vendor, subject to the review and approval of the Agencies in accordance with 
Contract Section 3.1-27.5. 


4.3 For each step, a NAC must be issued for all of the work tasks identified in the plan before moving 
to the next step. Final Acceptance shall be conditioned on KCM's use of the new AFC 
Application, RCU Application and OBS Application in revenue service on a minimum of 100 
coaches for at least 120 calendar days without experiencing any Severity 1 or severity 2 issues. 
ERG shall be responsible for Severity issues related to the AFC and RCU Applications. The 
County's OBS/CCS contractor shall be responsible for Severity issues related to the OBS 
Application. 
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5.0 Documentation Updates 

5.1 The Contractor shall modify all applicable design documents to reflect the changes that are 
made to the DDU, OBFTP and RCU designs, prior to issuance of a NAC for Final Acceptance of 
the work of this Change Order. 

5.2 The Contractor shall review and provide corrective comments on the revised KCM DDU user 
guides and training materials supplied by the OBS/CCS vendor. Contractor’s responsibility for 
review and corrective comments on materials supplied by the OBS/CCS vendor shall be limited 
to references to and descriptions of Contractor supplied solutions under this Change Order. 

5.3 The Contractor shall update, provide more details and otherwise modify its description of the 
certification process for non-RFCS applications to incorporate lessons learned from the process 
used under this Change Order. The Parties agree this will be provided at no additional charge 
to satisfy the base Contract Section 6.III-6-8.7. 

5.4 All documentation updates shall be submitted for review and approval to the Contract 
Administrator and the KCM OBS/CCS Project Manager, subject to the review and approval of 
the Agencies in accordance with Contract Section 3.1-27.5. 

6.0 Schedule 

Contractor shall coordinate with the OBS/CCS contractor to provide a detailed schedule of the tasks 
and document delivery dates related to this Change Order that is consistent with the "no later than" 
dates specified below. Said detailed schedule shall be submitted within fifteen (15) working days after 
receipt of this executed Change Order and shall be submitted to the Contract Administrator and the 
KCM OBS/CCS Project Manager, subject to review and approval by the Agencies in accordance with 
the process under Sec. 3.1-27.5. No changes may be made to the schedule without the written 
approval of the parties. 

7.0 Deliverables, Milestones and Payments 

7.1 The Deliverables and other Work under this Change Order shall be provided by the Contractor 
according to four milestones and shall be reviewed in accordance with the provisions of the 
Contract including but not limited to Section 3.1-27.5 and 3.1-27.6. 

7.2 Milestone 1: Design Review and Approval (Plan Step 1) 

7.2.1 The following tasks/deliverables shall be completed in accordance with the requirements not 
later than schedule task number QBS-MS1-100 . 

1-A: Specific Plan for FIM Design, Testing and Certification: The Contractor shall submit a 
plan to complete all work as described in Section 4.0 above, the test scripts, the 
schedule, and process steps for distributing the new CD, applications and updates to the 
test vehicles, and the method and duration of testing. Such plan shall be submitted to 
the Contract Administrator within fifteen (15) working days of issuance of this Change 
Order for review and approval by the KCM OBS/CCS Project Manager and the OBS/CCS 
vendor. 

1-B: Review of Contractor's Design: The Contractor shall make all necessary updates all 
applicable design documents to reflect the FIM design changes to the AFC Application 
and RCU Application and the development of the OBS Stub and DDU Monitor 
Applications, as more fully described in Section 2.0 of this Change Order, including but 
not limited to the following: 
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• Documentation components of the DDU Software Development Kit (SDK) including: 

o Win CE .NET 5.0 SDK - The SDK for the DDU’s particular build of Win CE 

o RCU Source Code - The source code for the current RCU application, which 
can be used as an example to the help aid 3rd party developers. 

o Software Libraries and Header Files - The Header files define the Application 
Programmers Interface (API) available to the 3rd Party programmer to 
interface with the DDU’s executive application suite. The software libraries 
include the executable code for the executive suite and device drivers. 

o IDC - Integrated Development Center is a graphical tool used to create and 
modify screens, templates and key assignments for the DDU graphical 
interface. 

o IDC Users manual - The users guide for the IDC. 

o GenAppaCE - A utility used to generate application upgrade files used during 
the automatic upgrades of in-field devices. 

o DPG-00393 Guidelines for Third-Party Integrators - Developers Manual 
describing the DDU and its development environment from a high level. This 
document also covers the API’s for the executive applications. 

o SEA-02123 DC5000 Guidelines for Third-Party Integrators (KCM Specifics) - 
Developers manual that describes the RCU application in detail 

o DPG-00711 DC5000 Device Driver API Specification - The developer’s 
manual describing the interface to the device drivers. 

o SEA-01064 On-Board Equipment Icon Library - a catalogue of existing icons 
and graphics as used by the DDU. 

o SEA-03026 DDU Compliance Form - A form to be filled out and returned with 
an application that is ready for certification. 

• Affected DR documents (including but not limited to screenflows) and the following: 

o SEA-01048 Driver Display Unit (DR 103B) - Functional Specification 

o SEA-01050 Fare Transaction Processor (DR 102B) - Functional Specification 

o SEA-00241 Radio Control Unit (DR103.06) 

The updated documents shall be submitted to the Contract Administrator within forty-five 
calendar days after issuance of this Change Order, for review and approval of the KCM 
OBS/CCS Project Manager. 


1-C Review of OBS/CCS Vendor's Design: The Contractor shall review and provide 
comments on the design documents for the OBS Application as submitted by the OBS/CCS 
vendor currently scheduled for schedule task number OBS1160 . No later than fifteen (15) 
working days after receipt of said design documentation, the Contractor shall provide a written 
statement to the Contract Administrator, the KCM OBS/CCS Project Manager and the OBS/CCS 
vendor either certifying the design as acceptable or providing a detailed explanation of what must 
be changed and how the OBS/CCS vendor must address any omissions, errors, deficiencies or 
other problems to obtain the Contractor's certification. 
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7.2.2 Upon completion in accordance with the requirements of the Work of Milestone 1: Design 

Review, the Contractor shall submit a written notice as provided in Contract section 3.1-27.6 to 
the Contract Administrator for review by the KCM OBS/CCS Project Manager. Issuance of a 
NAC shall be subject to the terms of Contract Section 3.1-27.6. Upon issuance of a NAC for 
Milestone One, the Contractor may submit an invoice for 30% of the total price due for this work 
under Section 8.2 below and any pre-approved travel expenses in accordance with Section 8.3 
below. 

7.3 Milestone 2: Development and FAT/SIT Testing (Plan Step 2) 

7.3.1 The following tasks/deliverables shall be completed in accordance with the requirements not 
later than schedule task number QBS-MS2-1000. 


2-A: Contractor Development Work: The Contractor shall complete development of the 
modified AFC and RCU Application as well as the OBS Stub and DDU Monitor 
Applications in accordance with the design NAC'd in Milestone 1: Design Review or any 
modifications to the design as subsequently approved in writing by the Contract 
Administrator. 

Contractor shall support the OBS/CCS vendor development effort and, if required, provide 
modifications to the DDU SDK materials as soon as they are identified. 

2-B: Factory Acceptance Testing and Systems Integration Testing: The Contractor shall 
work with the OBS/CCS vendor at Contractor’s facility in Perth, Australia to conduct FAT 
and SIT of their respective software elements implementing the FIM design, including but 
not limited to: 

a. Bench testing of the FIM DDU screens and functionality 

b. Integrated operation of the AFC, DDU and OBS 

c. End-to-end testing of the RFCS data flow: KCM > Clearing House > BOC > DAC > 

DDU and OBS/CCS data flow: KCM > MOBILEplan > VLU. 

The Parties agree that KCM representatives may witness any testing. No later than 
fifteen (15) working days after the FAT and SIT test periods, respectively, the Contractor 
shall provide a FAT report and a SIT report to the Contract Administrator, OBS/CCS 
Project Manager and the OBS/CCS vendor. Each report shall include: raw data collected 
and a summary and analysis of the results. Each report shall either certify that the test 
was successfully completed or provide a detailed explanation of what must be changed 
and a plan for how the Contractor and the OBS/CCS vendor will address any omissions, 
errors, deficiencies or other problems in order to successfully complete the test. The 
Contractor shall repeat the FAT and SIT as necessary until each has been successfully 
completed in accordance with the requirements. 

2-C: Updated Release and Test Plans: The Contractor shall submit updated Plans for Steps 3 
through 4 to the Contract Administrator, for review and approval by the KCM OBS/CCS 
Project Manager and review and coordination with the OBS/CCS vendor. The final plans 
for each step shall include a detailed description of the process for releasing the 
Contractor's AFC, Stub, DDU Monitor and RCU Applications, and the OBS Application, to 
all applicable DAC’s and coaches in the RFCS, including all steps leading up to loading 
the applicable revisions onto DDU’s on all of the Agencies coaches across the region. The 
plan shall also describe the process for coordinating CD updates with OBS data updates 
to ensure consistent data sets are maintained per this change order to the RFCS Contract 
section 6-111 6.8.5.5 (f). 
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7.3.2 Upon satisfactory completion of the Work of Milestone 2: Development and FAT/SIT Testing, the 
Contractor shall submit a written notice as provided in Contract section 3.1-27.6 for review by the 
Contract Administrator and the KCM OBS/CCS Project Manager. Issuance of a NAC shall be 
subject to the terms of Contract Section 3.1-27.6. Upon issuance of a NAC for Milestone Two, 
the Contractor may submit an invoice for 30% of the total price due for this work under Section 
8.2 below and any pre-approved travel expenses in accordance with Section 8.3 below. 

7.4 Milestone 3: Installation & Testing (Plan Steps 3-4) 

7.4.1 The following tasks/deliverables shall be completed not later than schedule task number OBS- 
MS3-1000 in accordance with the agreed upon schedule and requirements. The installation and 
testing program will include deployment of the Contractor’s application to the RTB to support two 
distinct phases of testing: 3-A.1 KCM Functional Prototype Testing and 3-A.2 Standard RTB 
Testing. During the Milestone 3-A test periods and this point forward, the Contractor will not be 
responsible for issues tracking, management or reporting on issues raised against the OBS/CCS 
Vendor supplied software or hardware. KCM is responsible for the provision of all test scripts 
and test procedures to be used in the functional prototype and RTB test phases. 


3-A.1: KCM Functional Prototype Testing: 

i. The Contractor shall deliver the FIM software that successfully passed SIT, to the 
RTB to provide KCM the ability to perform integration testing of the OBS/CCS 
application with other non RFCS on board systems. 

ii. KCM will purchase or supply reouired OBFTP and DDU units. The Contractor will 
commission these devices as test devices. The devices will not connect to the 
Production systems (i.e. KCM production DACsf. KCM will order and produce test 
cards for the integration testing. 

iii. KCM will supply a second test rig for use in the RTB. 

iv. The Contractor will supply updated CD payloads either on reguest from KCM to 
support integration testing or if an updated FIM application software version is 
released. The Contractor will work with KCM to coordinate access to the RTB to 
allow KCM to manually connect test devices to download the payloads . 

3-A.2: Standard Agency RTB Testing: 

v. i. The Contractor shall deliver to the RTB the modified AFC Application and RCU 
Application, new OBS Stub and DDU Monitor Applications and the OBS Application 
for testing by the Agencies. Following the RTB testing period, the Contractor shall 
provide an RTB test report to the Contract Administrator. OBS/CCS Project 
Manager and the OBS/CCS vendor. The report shall include a summary and status 
of issues raised against the Contractor’s observations on the RTB testing 
undertaken bv the Agencies and provide the Contractor’s opinion on whether the 
standard RTB testing phase was successfully completed, or provide the plan 
resolving outstanding Contractor issues. 
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The remainder of Milestone 3 Contractor activities will be deemed complete upon 
resolution of issues reported by the OBS/CCS Proiect Manager. Upon promotion 
to the Production environment of the FIM application, the Contractor will 
investigate issues raised bv the OBS/CCS Proiect Manager for FIM enabled 
buses. Issue identified as not caused by the Contractor’s software or hardware will 
be closed. 

Should the root cause of any issue raised bv the OBS/CCS Proiect Manager be 
confirmed as the Contractor's software, a solution will be provided and scheduled 
via a maintenance release. 

Upon verification of the solution in the Production environment, the Contractors 
participation in Milestone 3 will be complete. Subseguent issues raised on KCM 
production bus fleets will be managed via the standard issue management 
process. 


3-B Field Test: The Contractor shall release FIM applications and data for limited distribution 
to the KCM selected field test coaches. Up to five revenue vehicles will be equipped with 
OBS/CCS & TRS systems. Testing of FIM shall be conducted in accordance with the 
approved Plan for Step 4, and include testing as a part of the OBS/CCS vendor's 
installation prototyping and field testing activities. The County shall be responsible for 
providing all necessary test scripts and conducting the Field Test. 


7.4.2 Upon satisfactory completion of the Work of Milestone 3-A.1 KCM Functional Prototype Testing, 
the Contractor shall submit a written notice as provided in the Contract section 3.1-27,6 for 
review by the Contract Administrator and the KCM OBS/CCS Proiect Manager. Issuance of a 
NAC shall be subject to the terms of Contract Section 3.1-27.6. Upon issuance of a NAC for 
Milestone 3.A-1, the Contractor may submit an invoice for 100% of the total price due for this 
work. 

7.4.3 Upon satisfactory completion of the Work of Milestone 3-A.2: Standard Agency RTB Testing, t h e 
Contractor shall submit a written notice as provided in Contract section 3.1-27,6 for review by the 
Contract Administrator and the KCM OBS/CCS Proiect Manager. Issuance of a NAC shall b e 
subject to the terms of Contract Section 3.1-27.6. Upon issuance of a NAC for Milestone 3-A.2 ^ 
the Contractor may submit an invoice for 30% of the total price due for this work under Section 
8.2 below and any pre-approved travel expenses in accordance with Section 8.3 below. 

7.5 Milestone 4: Acceptance Testing and Final Documents 

7.5.1 The following tasks/deliverables shall be completed in accordance with the requirements not 

later than schedule task number QBS-MS4-1000. 
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4-A: Acceptance Testing: The Contractor shall release all FIM applications and data to the 
BOODAC for distribution to the all KCM coaches and the Stub Application to all other 
Agency coaches. Acceptance testing of the FIM designs shall be conducted in 
accordance with Section 4.3 above and the approved Design Review and Testing Plan, 
including but not limited to testing as a part of the OBS/CCS vendor's pilot testing 
activities. 

i. No later than fifteen (15) working days after the Acceptance Test period provided in 
Section 4.3 above, the Contractor shall provide a report to the Contract Administrator, 
OBS/CCS Project Manager and the OBS/CCS vendor. The report shall include: a 
summary and status of issues raised and vetted against the Contractor’s supplied FIM 
application. Where issues remain open against the Contractor’s FIM application, the 
report shall provide the plan to resolve outstanding Contractor issues. The report shall 
either certify that the acceptance testing was successfully completed or provide a detailed 
explanation of what must be changed and a plan for how the Contractor and the 
OBS/CCS vendor will address any omissions, errors, deficiencies or other problems in 
order to successfully complete the acceptance testing. The Acceptance Testing period 
shall be continued until the criteria in Section 4.3 have been satisfied. 

ii. The Contractor is not responsible for issue tracking for non-Contractor issues/defects. 

Hi. The Agencies are responsible for the provision of test scripts and procedures for use in 
the Acceptance Test Period. 

iv. Upon resolution of any Severity 1 or 2 development issues (DEVIs) raised during the 
Acceptance Testing phase against the Contractor’s FIM application, the Contractor shall 
submit a written notice to indicate completion of all Contractor scheduled Work of 
Milestone 4-A Acceptance Testing. Any development issues raised against the 
Contractor’s FIM application software shall not be considered applicable to the body of 
work required to complete the FSA Contract Milestone. 

4-B Revisions to Certification Process: Upon commencement of Milestone 4, the 

Contractor shall modify the Non-RFCS_Application Certification Process document and 
incorporate comments on the certification process, “lessons learned”, and address 
comments from the Contract Administrator and the KCM OBS/CCS Project Manager. 

4-C Software Updates: The Contractor shall track and manage all issues, bugs or faults 
identified with the Contractor FIM application via the standard RFCS issue management 
and Change Management processes. The Contractor shall provide revised, tested 
software modifications to resolve these issues. 

i. The Contractor will work with the OBS/CCS Proiect Manager to implement an additional 
release of the MPT Client software application as part of a scheduled maintenance 
release, provided that the OBS/CCS vendor’s software can be released to the Contractor, 
and the implementation scheduled without adverse impact on the agreed Milestone exit 
criteria as defined in Section 7.5.2 of this Change Order. This New Work will be 
scheduled and agreed via a written Change Order. 

ii. Software releases will be managed as part of the standard Release Management 
process. 

4-D Documentation Updates: The Contractor shall make all necessary updates to the 

applicable design documents, including those listed in Section 7.2.1, 1-B, to reflect any 
changes made during the testing and certification process. 

The updated documents shall be submitted for review and approval to the Contract 
Administrator, the KCM OBS/CCS Project Manager and the OBS/CCS vendor. 
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7.5.2 Upon satisfactory completion of the Work in 4-A of Milestone 4: Acceptance Testing and Final 
Documents, the Contractor shall submit a written notice as provided in Contract section 3.1-27.6 
for review by the Contract Administrator and the KCM OBS/CCS Project Manager. Issuance of 
a NAC shall be subject to the terms of Contract Section 3.1-27.6. Upon issuance of a NAC for 
Milestone 4, the Contractor may submit an invoice for the remaining 10% of the total price due 
for this work under Section 8.2 below and any pre-approved travel expenses in accordance with 
Section 8.3 below. 

8.0 Compensation 

8.1 The Contractor's full additional compensation for performing any and all Work required under this 

Change Order shall be the fixed compensation (as provided in Section 8.2) plus reimbursement 
of eligible travel expenses (as described in Sec. 8.3) 

8.2 Exhibit 9, Price Schedule, is hereby amended without further execution as provided in 
Amendment 28, attached hereto as "Change Order No. 32-Attachment A", to add a new 
Section XX to provide the fixed compensation due for all the Work of this Change Order. This 
additional compensation is agreed upon by the Parties in the interest of avoiding disputes, 
including disputes over the number of hours, the rates applied and whether certain types of 
hours are compensable. The Parties have agreed, without any admissions or concessions but 
in the interests of compromise and settlement, that the above amount is the full amount due for 
any and all Work added by this Change Order. Provided, however, the Parties further agree 
that this compromise and settlement does not apply to, and shall not be construed as a 
controlling precedent for any subsequent Change Orders. 

8.3 The Contractor shall be eligible for reimbursement of travel expenses for the following trips: 

1. Allowance for one software engineer to travel to Germany for 1 week to provide face-to- 
face technical support to the OBS/CCS vendor in its development efforts. 

2. Allowance for one software engineer to travel to Germany for 1 week to assist the 
OBS/CCS vendor in integrating the OBS Application with the AFC Application. 

3. Allowance for one test engineer to travel to Seattle for 4 weeks to observe and participate 
in the RTB and other testing and certification of the OBS Application. 

Travel hours are not compensable but travel expenses shall be reimbursed by the County to the 
extent the travel was only required to perform the work of this Change Order and was approved 
in advance by the OBS/CCS Project Manager. Travel expenses incurred for the above three 
purposes will only be eligible for reimbursement in accordance with limits specified in Contract 
Exhibit 9, Section I (A)(1)(c); and shall not exceed the total maximum of $19,000. 

9.0 Other Terms and Conditions 

Except as expressly amended by this Change Order, the Contract remains in full force and effect. All 

other provisions of the Contract not referenced in this Change Order 32 shall remain in effect unless 

modified in other executed Amendments and Change Orders. 
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IN WITNESS WHEREOF, the parties hereto have executed this Change Order No.32 to 
Contract #229944 as of the date set forth below its signature. 

ERG Transit Systems (USA) Inc. The Agencies 


By: 


By: 


Its: ____ Their:_ 

On behalf of the Agencies 

Date:_ Date:_ 


Central Puget Sound Regional Transit 
Authority 

By:_ 

Its:___ 

Date:___ 


King County 


By: _ 
Its: _ 
Date: 


Pierce County Public Transportation 
Benefit Area 


By: _ 
Its: _ 
Date: 


Washington State Ferries, Washington 
State Department of Transportation 


By: _ 
Its: _ 
Date: 


City of Everett 


By:_ 

Ray Stephanson, Mayor, or His Designee 
Date:___ 

ATTEST: 

By:__ 

Sharon Marks, City Clerk 
Date:___ 

APPROVED AS TO FORM: 

By:_ 

Everett City Attorney 

Date:___ 

Kitsap County Public Transportation 
Benefit Area 


By: _ 
Its: _ 
Date: 


Snohomish County Public 
Transportation Benefit Area 


By: _ 
Its: _ 
Date: 
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Change Order No. 32 - Attachment A 


Amendment 28 
to the 

Contract for the Design, Implementation, Operation and Maintenance of the Regional Fare 

Coordination System 


This Amendment 28 to the Contract for the Design, Implementation, Operation and Maintenance of the 

Regional Fare Coordination System is entered into this_day of January, 2008, by and between ERG 

Transit Systems (USA) Inc, a California corporation and wholly owned subsidiary of ERG Limited, an 
Australian corporation, (hereinafter referred to as the "Contractor") and each of the following seven 
public transportation agencies (hereinafter referred to individually as an "Agency" or collectively as 
the "Agencies"): 

1. Central Puget Sound Regional Transit Authority ("Sound Transit") 

2. King County ("King County") 

3. Kitsap County Public Transportation Benefit Area ("Kitsap Transit") 

4. Pierce County Public Transportation Benefit Area ("Pierce Transit") 

5. Snohomish County Public Transportation Benefit Area ("Community Transit") 

6. City of Everett ("Everett") 

7. State of Washington, acting through the Washington State Department of Transportation, 
Washington State Femes Division ("WSF") 

Recitals 

A. Effective April 29, 2003, each of the Agencies and the Contractor entered into Contract 
#229944 ("Contract") to implement a Regional Fare Coordination System ("RFC System") to establish 
a common fare system utilizing smart card technology. The Contractor is responsible for the 
development, implementation, operation and maintenance of the RFC System as specified in the 
Contract. 

B. This amendment is to add the fixed compensation due for the Contractor's Work performed 
under Change Order 32 related to implementation of King County's Full Integration Mode. 


NOW, THEREFORE, in consideration of the mutual covenants contained herein, the sufficiency of 
which is hereby acknowledged, the Agencies and the Contractor hereby agree to amend the Contract as 
follows: 
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Section 1.0 Price Schedule 

Exhibit 9, Price Schedule, is amended by adding the following new Section XX, entitled, "King 
County Full Integration Mode," after Section XIX, "King County Radio Control Unit." 

XX. KING COUNTY FULL INTEGRATION MODE 

Per Section 6.III-6.8.5 and Change Order 32 $178,599 

Section 2.0 Payment 

The amount added to the Price Schedule Exhibit 9 shall be due and payable in accordance with the 
provisions of Change Order 32. 
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Change Order No. 32 - Attachment B 


Amendment 128 
to the 

Contract for the Design, Implementation, Operation and Maintenance of the Regional 

Fare Coordination System 


This Amendment 128 to the Contract for the Design, Implementation, Operation and 
jtenarifcgrof the Regional Fare Coordination System is entered into this ^^ day of 
2012, by and between Vix Technology (USA) Inc (formerly known as ERG 
Systems (USA) Inc), a California corporation and wholly owned subsidiary of Vix 
Mobility Pty Ltd, an Australian corporation, (hereinafter referred to as the "Contractor") and 
each of the following seven public transportation agencies (hereinafter referred to individually 
as an "Agency" or collectively as the "Agencies"): 


Maintenance'of 

rkflftXs , 

Transit Systems 


1. Central Puget Sound Regional Transit Authority ("Sound Transit") 

2. King County ("King County") 

3. Kitsap County Public Transportation Benefit Area ("Kitsap Transit") 

4. Pierce County Public Transportation Benefit Area ("Pierce Transit") 

5. Snohomish County Public Transportation Benefit Area ("Community Transit") 

6. City of Everett ("Everett") 


7. State of Washington, acting through the Washington State Department of 
Transportation, Washington State Ferries Division ("WSF") 


Recitals 


A. Effective April 29, 2003, each of the Agencies and the Contractor entered into 
Contract #229944 ("Contract") to implement a Regional Fare Coordination System ("RFC 
System") to establish a common fare system utilizing smart card technology. The Contractor 
is responsible for the development, implementation, operation and maintenance of the RFC 
System as specified in the Contract. 

B. The Agencies and the Contractor desire to amend the description of Work in Change 
Order 32 to align with the Work, Schedules and Payment Milestone entry/exit criteria as 
implemented and as described in RFI RFCS 607 FIM Distribution for KCM OBS. This 
Amendment 128 is attached hereto as Change Order 32-Attachment B. 

NOW, THEREFORE, in consideration of the mutual covenants contained herein, the 
sufficiency of which is hereby acknowledged, the Agencies and the Contractor hereby agree 
to amend the Contract as follows: 
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Section 1.0 Description of Work 

1.1 By mutual agreement, Change Order 32 has been modified to describe the Work, 
Schedule and Payment Milestone entry/exit criteria with all modifications shown in the 
body of Change Order 32 in underlined text . 

Section 2.0 Compensation Changes 

2.1 There is no additional compensation associated with this Amendment 128 

Section 3.0 Other Terms and Conditions 

All other provisions of the Contract not referenced in this Amendment One Hundred and 
Twenty-eight shall remain in effect. 


IN WITNESS WHEREOF, authorized representative of the Agencies and the Contractor have 
signed their names in the spaces provided below. 


Vix Technology (USA) 

BV 7 ) 

Its: KVloyna 

Date:_ j^ %j / 2 - _ 


The Agencies 
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